\chapter{Testing | Tobias Lauffer}\label{chap:testing}
The chapter Testing includes testing and requirement verification of the Green Gadget Inc. online shop. For testing the online shop a Test Manager performs the web shop tests, which includes the activities of finding the test cases, executing them as well as comparing them to their requirements and finally report passed tests or problems with test cases.

For the documentation of the test cases process also the UML tool Enterprise architect was used. The great advantage is that test cases can be directly matched to their requirements. Over different states ("Proposed", "Implemented", "Validated") which are also represented with a colour it is possible to have the current state of the test cases.
\begin{figure}[ht]
	\centering
	\includegraphics[width=1\textwidth]{images/TestCasesMappedToReqs}
	\caption{Test cases are matched to their requirements}
	\label{fig:TCsToReqs}
\end{figure}

\section{Functional Requirements Check}
The following paragraphs will summarize related requirements to groups and give an introduction on how they are realised within the Webshop. The requirements will be listed only with their titles and not with the full text in prose. The whole requirements can be seen in chapter Project analysis.
\newpage

\subsection{Customer Registration and Login}
\begin{description}
	\item[REQ010] Create a customer account
	\item[REQ020] A customer shall be able to enter and edit personal data
	\item[REQ030] Customer login
\end{description}
The following screenshots in figure \ref{fig:TEvalUserLogin} of the Webshop shows the user options, which are determined by the requirements. At the top level of a user authentication a user can either register as new user or login via an email address and a password if the person was registered earlier. After a successful login, the Webshop welcomes the user with its full name. On the one hand this will be realised by a message "Hello <User>" on the start page, on the other hand a little border with some user options are depicted on the top right corner. Users can also logout at this control panel.
\begin{figure}[ht]
	\centering
	\includegraphics[width=1\textwidth]{images/TestEvalUserLoginOptions}
	\caption{Evaluation of user login options}
	\label{fig:TEvalUserLogin}
\end{figure}

\newpage
\subsection{Product Handling}
\begin{description}
	\item[REQ040] See products and read additional information
	\item[REQ050] Rating and review
	\item[REQ060] Product search
\end{description}
Users who want to buy products from the online store do have the possibility to see products and additional information from the manufacturer. For registered users, which are also denoted as customers in the context of the Webshop, can rate and review a bought product with their experience and meaning. Additional products can be searched over a search field in the top left corner of the Webshop. If available there are additional multimedia information like little promotional films. The following picture (\ref{fig:TestProductPage}) shows an overview of a product, with a price, a product description, some pictures and the product name. Additional a user entry with a rating of the product is depicted.
\begin{figure}[ht]
	\centering
	\includegraphics[scale=0.7]{images/TestProductPage}
	\caption{Product with additional information}
	\label{fig:TestProductPage}
\end{figure}

\newpage
\subsection{Buy Products}
\begin{description}
	\item[REQ070] Buy products
	\item[REQ080] Shopping cart
	\item[REQ090] Payment
	\item[REQ100] Confirmation E-Mail
\end{description}
Products that were selected from a user on the Webshop can be ordered by pressing the button "add to Cart". The shopping cart of the online shop can be reached as  registered or anonymous customer. It shows the selected products in order of the time the products were put into the shopping cart. In the shopping cart the customer can edit its appointment again and change the amount of a specific product or delete it from the cart. From the shopping cart to a finished order five steps are necessary.
\begin{enumerate}
	\item Configure the cart (Continue without configuration is also possible)
	\item If the address differ from configured address it can be changed
	\item Define payment and shipping method
	\item Submit the order
	\item Request a confirmation mail
\end{enumerate}
The different steps, especially the current step, are also depicted on the top of the whole process. The realised cart and payment system can be seen in picture \ref{fig:TestOrderProduct}. The TestCases inspected the whole process of buying products as well as the email confirmation communication.
\begin{figure}[ht]
	\centering
	\includegraphics[width=1\textwidth]{images/TestOrderProduct}
	\caption{Order process of products}
	\label{fig:TestOrderProduct}
\end{figure}

\subsection{Newsletter}
\begin{description}
	\item[REQ110] Newsletter subscription
	\item[REQ120] Newsletter un-subscription
	\item[REQ130] Newsletter confirmation
\end{description}
A newsletter can be ordered in two ways. As an anonymous user there is a possibility to request a newsletter by adding the email address into the appropriate field on the right view of the online shop. As registered user it is also possible to request a newsletter by setting a Checkbox at the order process.

After the request of the newsletter an email will be sent to the given email address, which has to be confirmed by the user. This mechanism shall avoid that arbitrary mail address will be added to the newsletter list. The realisation of the newsletter can be seen in the following depiction. The test case has evaluated, that all postulated requirements has been implemented by the Webshop

On executing the test cases for the newsletter a bug in the settings of the remailer was found. While sending the newsletter from the administration console (see next paragraph), no email was received by the registered customers. This behaviour was caused of a setting in the remailer of the Oxid shop, which had declared the newsletter as Spam mail. By choosing the correct settings this behaviour was corrected by the shop administrator.

\begin{figure}[ht]
	\centering
	\includegraphics[width=1\textwidth]{images/TestNewsletter}
	\caption{Extraction of the GreenGadget Inc. newsletter}
	\label{fig:TestNewsletter}
\end{figure}

\newpage
\subsection{Webshop Administration}
\begin{description}
	\item[REQ140] Separation of roles
	\item[REQ150] Create administrator account
	\item[REQ160] Administrator login
	\item[REQ170] Product management
	\item[REQ180] User management
	\item[REQ190] Advertising management (e.g. newsletter)
\end{description}
The requirements define a separation of roles in the frontend and backend of the Webshop, where different persons can have different privileges, so e.g. that an administrator of the site can be also a customer. The privileges of an administrator on the backend are unlimited. There are additional roles like a product care and maintenance role which is only responsible for the products. Additional privileges are e.g. sending newsletters or creating a "Special of the week". The shop administrator allocates the user privileges. All requirements, and so the test cases, are covered by the backend of the Oxid Admin site. A screenshot of the backend with most of the functionality can be seen in picture \ref{fig:TestAdmin}.
\begin{figure}[ht]
	\centering
	\includegraphics[width=1\textwidth]{images/TestAdmin}
	\caption{The administration page}
	\label{fig:TestAdmin}
\end{figure}

\section{Non-functional Requirements}
Non-functional requirements are often requirements that can be answered with yes or no, e.g. the system can handle 200 users at the same time. So test cases do sometimes fade into the background because the requirements where fulfilled in a very early phase of the project, like the choice of a free software.
\subsection{Architectural aspects}
\begin{description}
	\item[REQ500] Frontend as Webpage over HTTP
	\item[REQ510] Backend as Webpage over HTTP
\end{description}
The frontend of the Webshop is the User interface for customers, where they can interact with the system. It is useful to realise the system as a Webpage with HTTP, because this is the common protocol and practically every user has a web browser. On the other hand a Webshop without a user interface based on web pages is nearly unthinkable.

The requirements where preconditions on the choice of an appropriate Webshop software for the project and so the test cases for these issues only had a theoretical character.

\subsection{System Aspects}
\begin{description}
	\item[REQ520] Runnable on common browsers
	\item[REQ530] Webshop is free software
	\item[REQ540] System is small
	\item[REQ550] System is easy to install
	\item[REQ560] System is simple to administrate
\end{description}
The test cases for these requirements had varying characteristics. While requirement 530 was responding with the answer "fulfilled", the requirements 540-560 has to be tested against distinct fine coarse rules. With a size of an installation package less than 50 MB the system was classified as small system. The satisfaction of requirement 550 and 560 where stated by the experience of the Webshop administrators and the possibility of executing different tasks under a distinct period of time.

The test case for requirement 520 required the system to run under the common browsers Internet explorer, Firefox, Mozilla and Google Chrome. All test cases were executed successfully without the need of a retesting.

\subsection{Performance and Capacity Aspects}
\begin{description}
	\item[REQ570] Response time (in less than five seconds)
	\item[REQ580] User traffic (100 users at the same time)
	\item[REQ590] Orders (20000 in a year)
\end{description}
Because of capacity aspects these requirements could not be tested in detail. However, an evaluation of them was performed by reading different experiences from users of the Oxid Webshop system. While the required numbers were widely below experiences of other companies these requirements can be seen as agreed.

\section{Usability Tests}
The shop was tested by chosen people with different ages and backgrounds to get a widespread feedback of the Webshops usability. On these tests it could be established that every user was able to perform a fully registration and order procedure without the help of a Webshop supporter.

A further eye capturing test shall analyze how features like the "Top of the week" or the "Tag cloud" will be perceived and recognized by one time and recurring users. This test will enable an assertion on the one hand of how objects can be placed better on the Webshop site to get more attention and on the other hand if elements with minor effect should be removed from the site.

\section{Summary}
At the end of the project phase all test cases could be performed successfully. Because of the test cases a configuration error in the newsletter functionality was found and removed. The actual state of the test cases with appropriate colors gave the possibility to see the current state of the project at every time. Because of the short communication ways the whole testing process was performed very effective and in a good manner.